讨论：开发大型后台管理系统，应该采用前后端分离吗？
The following article is from 四猿外 Author 四猿外
（给程序员的那些事加星标）
作者：四猿外 （本文来自作者投稿）
话说有一天我们团队开会，讨论了一个问题，与其说“讨论”，不如说“争吵”更合适。
背景是这样的：我们要开发一个 xxx 后台管理系统，这个系统业务复杂、功能又多，大家的争吵集中在“这个系统是否应该用前后端分离的方案”。
这次争吵的问题比较典型，于是我就写了这篇文章。为了大家好理解，把“xxx 后台管理系统”泛化一下，变成：开发一个大型后台管理系统，应该用前后端分离的技术方案吗？
先说一下，本文中的观点肯定有人不认同，再加上我对前端技术掌握有限，所以大家批判的看吧。
1. 先审题，冷静的分析一下
前后端分离的优点多多，这不需要多说，大家都清楚。
来，讨论之前，我们先一起好好审审题。
结合“开发一个大型后台管理系统”这个约束条件，冷静的分析一下：
• 什么是后台管理系统？
首先后台管理系统这个称呼，意味着这是一个 B 端系统。可以小到部门级应用（客户投诉登记系统、办公设备台账系统），大一点可以是大集团级核心系统（500 强保险公司客服、呼叫中心），可以是 ERP、CRM、OA（SAP、用友、泛微协同），可以是一个 B2C 电商的商城后台、支付网关管理控制台，可以是 Saas 的管理后台（Salesforce、Teambition、Jira），可以大到阿里云控制台……
• 什么是大型？
我理解大型系统是指功能模块多、交互复杂，而不是访问量、TPS、数据量大。所以 CMS、OA、ERP、CRM、阿里云后台、呼叫中心等各种管理系统，满足功能多、逻辑复杂，基本可以称为大型系统，虽然他们体量和交易量可能不在一个量级。另外大型系统基本等价于“维护周期长，需求不断变更”，这个在后面维护成本部分阐述。
• 性能考量不是主要决定因素：因为我们这里讨论的是 B 端系统的前端技术选型，因此我的观点是性能不是主要考虑因素，因为性能瓶颈往往在后端和数据库，其次 B 端产品少有爆发性交易量（秒杀 大促 活动），最后 B 端产品不强调首屏渲染速度。
• UI 操作效率是最主要考核指标：B 端系统产品都是用来干活儿、管理、生产调度的，操作效率和方便性大于天。屏幕空间要充分利用，减少切换跳转弹窗；快捷键效率远高于鼠标；SPA 多页签布局有利于保持工作上下文和状态；必要时可以鼠标右键菜单操作；功能菜单操作提示要清晰易理解，减少培训麻烦；在此基础上，尽量减少每一个界面上呈现的信息量，只呈现最少的必要信息，降低用户认知压力。
• UI 开发效率高、维护成本低是关键考量因素：大型系统基本等价于“维护周期长、需求不断变更”，因此在技术选型上尽量要求维护成本低、学习成本低、招聘容易、组件化程度高代码简洁……
• UI 颜值美观度不是关键考量方面：界面简洁大方、图表丰富、数据展现清晰，这其实本身就是一种美——朴素实用的美。
• 浏览器兼容性：这条要看具体情况——Saas要求兼容性高；内网系统、内部系统可以要求浏览器产品和版本。
2. 亮观点
基于上述，所以我的观点就是：前后端分离对于大部分“大型后台管理系统”来说弊大于利。
大型后台管理系统，相对于 C 端产品，B 端产品隐含等价于“业务逻辑复杂”。我不是说 B 端比 C 端产品难做，C 端有另外的难度（比如用户体验、比如竞品之间的竞争更加激烈、比如并发量挑战、比如做活动的需求频繁……）。
通常来说，复杂业务逻辑的产品需要产品、美工、开发各工种人员，密切配合、快速原型、MVP、快速迭代、快速试错。因此，由后端工程师全栈开发的效率、效果，要高于前后端分离（这里说的“效果”指的是趁热打铁和技术主观能动性的效果）。
那种“产品画框图、再到做设计稿、再到前端切图、最后扔给程序员渲染模板”的传统开发流水线，会彻底拖慢一个业务需求从想法到交付的周期，会彻底割裂整个团队，会遗漏大量的上下文信息，会增加巨大沟通成本，会彻底磨灭项目成员的参与感和对产品的归属感。
画图仔、切图仔和码农，按部就班像流水线拧螺丝一样开发产品，很难创建出一个有灵魂有灵性的产品！
更不用提前后端分离造成的开发、联调、部署、定接口、维护接口的成本提高。
另外，前后端分离也不适合项目型公司，因为项目周期有限，团队磨合的时间越少越好。还有，项目交付后，留守的人员配置不齐，导致需求变更和维护问题难以解决。
综上：前后端分离的开发和部署模式，不太适合“大型后台管理系统”，原因 一方面是上面列举的种种弊端，另一方面是大型后台管理系统无法享受到前后端分离的好处：Nginx 分开部署的优势、专业前端优势（C 端产品追求极致的颜值和用户体验）。
既然这么多弊端，为什么还有很多“大型后台管理系统”之类的项目，跟风搞前后端分离呢？
答案主要集中在两类：简历驱动的技术选型、盲目跟风。
3. 简历驱动的技术选型
软件开发绝对是个良心活儿，跟医生、教师一样的。
我这几年见到了太多的微型团队（10人以下）搞微服务架构，以及前后端分离的 CMS 内容管理系统！
见了太多为了用时髦技术而盲目选型的事情，太多不计后果、不计成本的追求新技术来美化自己简历，太多用流行技术名词忽悠自己不懂技术的老板、上司的情况。
你们的良心不会痛吗？
当你在简历上加上了一个个流行技术关键词，然后拍拍屁股离开了一个烂尾的项目、一个预算严重超支的项目，让创业团队多走几年弯路甚至夭折，你的良心和职业素养都破产了！
你正在透支技术人这个群体的社会声誉。
技术人的天职，本应是把复杂模糊的现实世界问题，建模成清晰逻辑结构化的计算机软硬件，让世界变得更简单高效，如果因为一些奇怪的原因而把简单问题复杂化，那就是背离了这个行业的初衷。
希望越来越多的甲方、非技术出身的高管们明白一个道理：
> 靠谱的人是把解决方案做的很简单以至于明显没有问题，不靠谱的人会把解决方案做的毫无必要的复杂以至于短时间内看不出明显的问题。
4. 前后端分离不是坏的，跟风才是坏的
前后端分离的出现和存在，当然有它的合理性和优势。
这里插一句，说起前后端分离，必须先介绍一下 Angular、React、Vue，绝对是前端领域的三大当红花旦。但是这三大花旦，也让无数码农陷入选择困难症，引发了大量无休无止的争论。很多讨论，当事人已经忘记了讨论的初衷和边界，最后陷入无意义的口水战。
看看谁创造了它们——谷歌的 Angular、Facebook 的 React、阿里的 antd、饿了么的 element、前谷歌程序员尤雨溪创建的 Vue。
总之就是大厂在创造和使用这些技术，这些技术能解决别人的问题，但是不一定能解决你的问题。
彼之良药，汝之砒霜。
所以我建议：在前后端分离、前端技术选型这种问题上不要盲目跟风，不要觉得跟着互联网大厂走就一定不会错。你需要清楚你的项目类型、团队结构、技术沉淀、开发周期……
如果你和大厂一样，不差钱、不缺资源，那没的说，尽管选最好最贵、对标一线大厂技术栈，甚至是直接从大厂挖人。
如果你是做项目赚辛苦钱，或者自己投资研发产品，在传统行业、在产业互联网精耕细作，慢慢摸索培育市场，不在风口不受风投追捧的，那我觉得你需要务实一些。
我建议各位本着务实和诚实的态度、职业精神操守，结合自己公司、团队、资源、项目、业务需求，选择最适合自己的技术栈。
欢迎留言讨论。
- EOF -
关注「程序员的那些事」加星标，不错过圈内事
圈内事，我在看❤️